Maxwell Krohn Research Statement And Agenda

Today’s computing trends are not favorable for data security. On the one hand, software systems are exploding in size and complexity, exposing more vulnerable code to attackers. On the other, users store more valuable data on their machines and on websites, giving attackers ever larger incentives. Industry’s approach is a game of catch-up, a constant stream of piecemeal security patches. In academia, we can strive for a better solution: to replace our ailing systems with secure alternatives. In my research, I build practical systems that are secure by design. Examples include the 2-Schnorr authentication system [8], the SUNDR file system [7], and a content distribution system [3]. I have particular interest in the web: a new web server (OKWS [2]) and new operating system primitives (Asbestos [1] and Flume [5]) offer inherently secure architectures for web systems. All of these systems begin with security principles—some of them invented anew, others inherited from a rich literature. To name a few examples, SUNDR proposes a relaxed definition of file system consistency, which the system provably upholds even if the server is malicious. OKWS applies the “the principle of least privilege” to sequester vulnerable code. Asbestos and Flume adapt the logic of mandatory access control (MAC) to web applications. In this respect, building secure systems is an intellectual exercise, one of finding the appropriate principle for the problem at hand, and arguing that the system instantiates the principle. But these systems are not just academic artifacts; they offer solutions to real-world problems because they cater to their principals—administrators, programmers, and end-users. Many secure systems fail because their defense mechanisms ensnarl attacker and honest user alike. My research, inspired by experience with real commercial web sites, emphasizes intuitive interfaces for programmers, deployable systems for administrators, and familiar UIs for end-users. For example, the security features of the Asbestos operating system were difficult to program with; the Flume system makes them compatible with the familiar Unix API. As another example, the SFS programming library allows development of secure distributed applications but demands a manual continuation-passing style. The Tame system simplifies SFS, so it now resembles familiar thread-based libraries [4]. Finally, OKWS has evolved over four years, its API continually refined at programmers’ requests. Success in real deployments validates this emphasis on usability and programmability: real commercial concerns use OKWS; Tame has caught on with research projects and OKWS programmers; and a start-up social networking website has expressed interest in Flume. Thus, a common progression in my research is to first identify a pressing security problem (e.g., rampant data theft on the web); then to find a suitable intellectual principle that addresses the problem (e.g., MAC); then to build and refine a practical system that follows the principle (e.g., Flume). In some cases, this line of work yields not just secure replacements but rather new kinds of applications. With much fanfare, sites like Facebook have opened their API to outside developers. The W5 proposal argues these architectures overly restrict developers and inadequately protect users [6]. New systems like Asbestos and Flume enable a better approach to building websites with open APIs, and Flume in particular is practical enough to make such a proposal a reality.